The present invention relates to the field of shared resource handling in a service environment, synchronizing shared resources in an order processing environment using a synchronization component.
It can be beneficial to be able to perform systems management for flows in a scope of an entire IT service environment. FIG. 1 (prior art) represents a system 100 for a resource topology that permits system management flows to be created and used. Additional details relating to the structure and implementation specifics of system 100 are disclosed in the cross referenced application entitled “Method and System for Dynamically Creating and Modifying Resource Topologies and Executing Systems Management Flows.” Discussions presented herein are a simplification of that topology for purposes of explaining the solution disclosed herein. The system 100 utilizes three abstraction layers including a system management flows layer 120, a system management layer 130, and an IT resources layer 140.
The flows layer 120 can interact with a systems management layer 130, which includes many different resource managers 132-138. These resource managers 132-138 can perform programmatic functions relating to resources of layer 140. These functions can control options of a resource, such as provisioning resources, de-provisioning resources, and otherwise controlling an operation and configuration of a series of resources. Managers 132-138 can include, but are not limited to, network device manager(s) 132, cluster manager(s) 134, storage device manager(s) 135, application manager(s) 136, server manager(s) 137, software image manager(s) 138, and the like. Using system management layer 130 changes can be made relating to the IT resources of layer 140 in a manner transparent to flows layer 120.
The IT resources layer 140 can include a set of computing resources 142-148, which perform computing functions. These resources 140 can be distributed across a network and can conform to numerous different platform specific and/or resource specific standards. Low-level standards of the resources 142-148 can be locally handled, such as by an operating system. The resources 142-148 can conform to numerous standards, which permits the systems manager(s) 132-138 to perform resource functions in a unified manner. For example, each of the resources 142-148 can include an interface and a set of published methods for interacting with the resource 142-148 through the interface. Resources, such as SOA system resources 147 and/or Enterprise Resource Planning (ERP) resources 148 can represent a supersets of component resources, which is able to be controlled and managed through a standardized interface and set of programmatic calls. An actual complexity of each resource 142-148 is arbitrary and each can be managed and controlled by one or more managers 132-138. The resources 142-148 can include, but are not limited to application resource(s) 142, storage device resource(s) 144, Web 2.0 system resource(s) 145, DB management system resource(s) 146, SOA system resource(s) 147, Enterprise Resource Planning (ERP) system resources, and the like.
The system management flows layer 120 can handle various flows 122-126 at a flow level. In one embodiment, each flow 122-126 can be associated with a flow order, which includes a number of discrete tasks (e.g., Tasks A, B, C, . . . N) that are to be conducted. On or more workflow engines 128 of layer 120 can ensure that each task is performed in accordance with tasks specifics. That is, from a management perspective, interactions for flows 122-126 can occur at a flow level by interacting with engines 128. In system 100, it is advantageous to maintain layer 130 as a layer of abstraction between layer 120 and layer 140, since it permits consistent handling of tasks in a resource 142-148 independent manner. Actual resources 142-148 utilized to handle discrete tasks and details therein can vary to an arbitrary extent, without affecting operations of work flow engine 128.
One heretofore unresolved challenge with system 100 relates to the concurrent handling of shared resources 142-148. That is, IT resources 142-148 may be concurrently used by two or more flows 122-126 executing in parallel. Present designs of system 100, therefore, often place a resource synchronization burden on a flow 122-126 designer. A designer of a flow 122-126 can therefore not just concentrate on application aspects of the flow, which is one significant benefit of system 100 over traditional work flow implementations. Further, an error in critical sections of flow 122-126 code can influence concurrent flows waiting to access a shared resource (through manager 132-138 exposed functions).